Hi @boennemann did you have any chance to take a look at this?

@rodoabad I initially was thinking along the same lines, then I read all the threads linked here and I realized that it's actually more desirable to have at least a patch version far any new commits being pushed.

Another way to look at it is that the responsibility to enforce a specific commit format is not within semantic-release scope, but rather the responsibility of libraries like commitizen.

Most importantly though, the summary of the semver threads linked in the comment above is that any change in the public version (no matter if it's docs, test, build tools, etc.) requires at least a new patch version.

This imho should be the default behaviour, then users could always pass different config parameters to the plugin, once a new version supports them as described here: semantic-release/commit-analyzer#3

👍

As per #11 I think @boennemann should deprecate commit-analyzer and migrate to conventional-recommended-bump.

@hbetts that's an option, would conventional-recommended-bump always suggest at least a patch upgrade if there are any new pushed commits?

Any news on this?
One year of silence on this suggest me that this repo is unmaintained ?

Any news on this?

@ayanozturk I'm using this: https://github.com/elliotttf/semantic-release-conventional-commits so I can configure what kind of commit triggers what kind of release

Conclusion

@ALL this repo is not maintained any more you need to do custom versions of sematic-release for your usecases